home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-ripv2-protocol-00.txt < prev    next >
Text File  |  1993-10-01  |  19KB  |  563 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Draft-ietf-ripv2-protocol-00.txt                               G. Malkin
  8. Obsoletes RFC 1388                                        Xylogics, Inc.
  9. Updates RFC 1058                                            October 1992
  10.  
  11.  
  12.                              RIP Version 2
  13.                     Carrying Additional Information
  14.  
  15.  
  16. Abstract
  17.  
  18.    This document specifies an extension of the Routing Information
  19.    Protocol (RIP), as defined in [1,2], to expand the amount of useful
  20.    information carried in RIP messages and to add a measure of security.
  21.  
  22.    A companion document will define the SNMP MIB objects for RIP-2 [3].
  23.  
  24.  
  25. Status of this Memo
  26.  
  27.    This document is an Internet Draft.  Internet Drafts are working
  28.    documents of the Internet Engineering Task Force (IETF), its Areas,
  29.    and its Working Groups.  Note that other groups may also distribute
  30.    working documents as Internet Drafts.
  31.  
  32.    Internet Drafts are draft documents valid for a maximum of six
  33.    months. Internet Drafts may be updated, replaced, or obsoleted by
  34.    other documents at any time.  It is not appropriate to use Internet
  35.    Drafts as reference material or to cite them other than as a "working
  36.    draft" or "work in progress."
  37.  
  38.    Please check the I-D abstract listing contained in each Internet
  39.    Draft directory to learn the current status of this or any other
  40.    Internet Draft.
  41.  
  42.    It is intended that this document will be submitted to the IESG for
  43.    consideration as a standards document.  Distribution of this document
  44.    is unlimited.
  45.  
  46.  
  47. Acknowledgements
  48.  
  49.    I would like to thank the IETF ripv2 Working Group for their help in
  50.    improving the RIP-2 protocol.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Malkin                      Expires: 1Mar94                     [Page 1]
  59.  
  60. Internet Draft               RIP Version 2                  October 1992
  61.  
  62.  
  63.                              Table of Contents
  64.  
  65.  
  66.    1.  Justification . . . . . . . . . . . . . . . . . . . . . . . . . 3
  67.  
  68.    2.  Current RIP . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  69.  
  70.    3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . 3
  71.    3.1   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 4
  72.    3.2   Route Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  73.    3.3   Subnet Mask . . . . . . . . . . . . . . . . . . . . . . . . . 5
  74.    3.4   Next Hop  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  75.    3.5   Multicasting  . . . . . . . . . . . . . . . . . . . . . . . . 6
  76.    3.6   Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
  77.  
  78.    4.  Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 6
  79.    4.1   Compatibility Switch  . . . . . . . . . . . . . . . . . . . . 7
  80.    4.2   Authentication  . . . . . . . . . . . . . . . . . . . . . . . 7
  81.    4.3   Larger Infinity . . . . . . . . . . . . . . . . . . . . . . . 7
  82.    4.4   Addressless Links . . . . . . . . . . . . . . . . . . . . . . 8
  83.  
  84.    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
  85.  
  86.    Appendicies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  87.  
  88.    References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
  89.  
  90.    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Malkin                      Expires: 1Mar94                     [Page 2]
  115.  
  116. Internet Draft               RIP Version 2                  October 1992
  117.  
  118.  
  119. 1. Justification
  120.  
  121.    With the advent of OSPF and IS-IS, there are those who believe that
  122.    RIP is obsolete.  While it is true that the newer IGP routing
  123.    protocols are far superior to RIP, RIP does have some advantages.
  124.    Primarily, in a small network, RIP has very little overhead in terms
  125.    of bandwidth used and configuration and management time.  RIP is also
  126.    very easy to implement, especially in relation to the newer IGPs.
  127.  
  128.    Additionally, there are many, many more RIP implementations in the
  129.    field than OSPF and IS-IS combined.  It is likely to remain that way
  130.    for some years yet.
  131.  
  132.    Given that RIP will be useful in many environments for some period of
  133.    time, it is reasonable to increase RIP's usefulness.  This is
  134.    especially true since the gain is far greater than the expense of the
  135.    change.
  136.  
  137.  
  138. 2. Current RIP
  139.  
  140.    The current RIP message contains the minimal amount of information
  141.    necessary for routers to route messages through a network.  It also
  142.    contains a large amount of unused space, owing to its origins.
  143.  
  144.    The current RIP protocol does not consider autonomous systems and
  145.    IGP/EGP interactions, subnetting, and authentication since
  146.    implementations of these postdate RIP.  The lack of subnet masks is a
  147.    particularly serious problem for routers since they need a subnet
  148.    mask to know how to determine a route.  If a RIP route is a network
  149.    route (all non-network bits 0), the subnet mask equals the network
  150.    mask.  However, if some of the non-network bits are set, the router
  151.    cannot determine the subnet mask.  Worse still, the router cannot
  152.    determine if the RIP route is a subnet route or a host route.
  153.    Currently, some routers simply choose the subnet mask of the
  154.    interface over which the route was learned and determine the route
  155.    type from that.
  156.  
  157.  
  158. 3. Protocol Extensions
  159.  
  160.    This document does not change the RIP protocol per se.  Rather, it
  161.    provides extensions to the message format which allows routers to
  162.    share important additional information.
  163.  
  164.    The first four octets of a RIP message contain the RIP header.  The
  165.    remainder of the message is composed of 1 - 25 route entries (20
  166.    octets each).  The new RIP message format is:
  167.  
  168.  
  169.  
  170. Malkin                      Expires: 1Mar94                     [Page 3]
  171.  
  172. Internet Draft               RIP Version 2                  October 1992
  173.  
  174.  
  175.     0                   1                   2                   3 3
  176.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  177.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.    | Command (1)   | Version (1)   |           unused              |
  179.    +---------------+---------------+-------------------------------+
  180.    | Address Family Identifier (2) |        Route Tag (2)          |
  181.    +-------------------------------+-------------------------------+
  182.    |                         IP Address (4)                        |
  183.    +---------------------------------------------------------------+
  184.    |                         Subnet Mask (4)                       |
  185.    +---------------------------------------------------------------+
  186.    |                         Next Hop (4)                          |
  187.    +---------------------------------------------------------------+
  188.    |                         Metric (4)                            |
  189.    +---------------------------------------------------------------+
  190.  
  191.    The Command, Address Family Identifier (AFI), IP Address, and Metric
  192.    all have the meanings defined in RFC 1058.  The Version field will
  193.    specify version number 2 for RIP messages which use authentication or
  194.    carry information in any of the newly defined fields.  The contents
  195.    of the unused field (two octets) shall be ignored.
  196.  
  197.    All fields are coded in IP network byte order (big-endian).
  198.  
  199. 3.1 Authentication
  200.  
  201.    Since authentication is a per message function, and since there is
  202.    only one 2-octet field available in the message header, and since any
  203.    reasonable authentication scheme will require more than two octets,
  204.    the authentication scheme for RIP version 2 will use the space of an
  205.    entire RIP entry.  If the Address Family Identifier of the first (and
  206.    only the first) entry in the message is 0xFFFF, then the remainder of
  207.    the entry contains the authentication.  This means that there can be,
  208.    at most, 24 RIP entries in the remainder of the message.  If
  209.    authentication is not in use, then no entries in the message should
  210.    have an Address Family Identifier of 0xFFFF.  A RIP message which
  211.    contains an authentication entry would begin with the following
  212.    format:
  213.  
  214.     0                   1                   2                   3 3
  215.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  216.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  217.    | Command (1)   | Version (1)   |            unused             |
  218.    +---------------+---------------+-------------------------------+
  219.    |             0xFFFF            |    Authentication Type (2)    |
  220.    +-------------------------------+-------------------------------+
  221.    ~                       Authentication (16)                     ~
  222.    +---------------------------------------------------------------+
  223.  
  224.  
  225.  
  226. Malkin                      Expires: 1Mar94                     [Page 4]
  227.  
  228. Internet Draft               RIP Version 2                  October 1992
  229.  
  230.  
  231.    Currently, the only Authentication Type is simple password and it
  232.    is type 2.  The remaining 16 octets contain the plain text password.  If
  233.    the password is under 16 octets, it must be left-justified and
  234.    padded to the right with nulls (0x00).
  235.  
  236. 3.2 Route Tag
  237.  
  238.    The Route Tag (RT) field is an attribute assigned to a route which
  239.    must be preserved and readvertised with a route.  The intended use
  240.    of the Route Tag is to provide a method of separating "internal"
  241.    RIP routes (routes for networks within the RIP routing domain)
  242.    from "external" RIP routes, which may have been imported from an
  243.    EGP or another IGP.
  244.  
  245.    Routers supporting protocols other than RIP should be configurable
  246.    to allow the Route Tag to be configured for routes imported from
  247.    different sources.  For example, routes imported from EGP or BGP
  248.    should be able to have their Route Tag either set to an arbitrary
  249.    value, or at least to the number of the Autonomous System from
  250.    which the routes were learned.
  251.  
  252.    Other uses of the Route Tag are valid, as long as all routers in
  253.    the RIP domain use it consistently.  This allows for the
  254.    possibility of a BGP-RIP protocol interactions document, which
  255.    would describe methods for synchronizing routing in a transit
  256.    network.
  257.  
  258. 3.3 Subnet mask
  259.  
  260.    The Subnet Mask field contains the subnet mask which is applied to
  261.    the IP address to yield the non-host portion of the address.  If this
  262.    field is zero, then no subnet mask has been included for this entry.
  263.  
  264.    On an interface where a RIP-1 router may hear and operate on the
  265.    information in a RIP-2 routing entry the following rules apply:
  266.  
  267.    1) information internal to one network must never be advertised into
  268.       another network,
  269.  
  270.    2) information about a more specific subnet may not be advertised
  271.       where RIP-1 routers would consider it a host route, and
  272.  
  273.    3) supernet routes (routes with a netmask less specific than
  274.       the "natural" network mask) must not be advertised where they
  275.       could be misinterpreted by RIP-1 routers.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Malkin                      Expires: 1Mar94                     [Page 5]
  283.  
  284. Internet Draft               RIP Version 2                  October 1992
  285.  
  286.  
  287. 3.4 Next Hop
  288.  
  289.    The immediate next hop IP address to which packets to the destination
  290.    specified by this route entry should be forwarded.  Specifying a
  291.    value of 0.0.0.0 in this field indicates that routing should be via
  292.    the originator of the RIP advertisement.  An address specified as
  293.    a next hop must, per force, be directly reachable on the logical
  294.    subnet over which the advertisement is made.
  295.  
  296.    The purpose of the Next Hop field is to eliminate packets being routed
  297.    through extra hops in the system.  It is particularly useful when RIP
  298.    is not being run on all of the routers on a network.  A simple example
  299.    is given in Appendix A.  Note that Next Hop is an "advisory" field.  That
  300.    is, if the provided information is ignored, a possibly sub-optimal,
  301.    but absolutely valid, route may be taken.
  302.  
  303. 3.5 Multicasting
  304.  
  305.    In order to reduce unnecessary load on those hosts which are not
  306.    listening to RIP-2 messages, an IP multicast address will be used for
  307.    periodic broadcasts.  The IP multicast address is 224.0.0.9.  Note that
  308.    IGMP is not needed since these are inter-router messages which are not
  309.    forwarded.
  310.  
  311.    In order to maintain backwards compatibility, the use of the
  312.    multicast address will be configurable, as described in section 4.1.  If
  313.    multicasting is used, it should be used on all interfaces which support
  314.    it.
  315.  
  316. 3.5 Queries
  317.  
  318.    If a RIP-2 router receives a RIP-1 Request, it should respond with a
  319.    RIP-1 Response.  If the router is configured to send only RIP-2
  320.    messages, it should not respond to a RIP-1 Request.
  321.  
  322.  
  323. 4. Compatibility
  324.  
  325.    RFC 1058 showed considerable forethought in its specification of
  326.    the handling of version numbers.  It specifies that RIP messages of
  327.    version 0 are to be discarded, that RIP messages of version 1 are
  328.    to be discarded if any Must Be Zero (MBZ) field is non-zero, and that
  329.    RIP messages of any version greater than 1 should not be discarded
  330.    simply because an MBZ field contains a value other than zero.  This
  331.    means that the new version of RIP is totally backwards compatible
  332.    with existing RIP implementations which adhere to this part of the
  333.    specification.
  334.  
  335.  
  336.  
  337.  
  338. Malkin                      Expires: 1Mar94                     [Page 6]
  339.  
  340. Internet Draft               RIP Version 2                  October 1992
  341.  
  342.  
  343. 4.1 Compatibility Switch
  344.  
  345.    A compatibility switch is necessary for two reasons.  First, there
  346.    are implementations of RIP-1 in the field which do not follow RFC
  347.    1058 as described above.  Second, the use of multicasting would
  348.    prevent RIP-1 systems from receiving RIP-2 updates (which may
  349.    be a desired feature in some cases).  This switch should be configurable
  350.    on a per-interface basis.
  351.  
  352.    The switch has four settings: RIP-1, in which only RIP-1 messages are
  353.    sent; RIP-1 compatibility, in which RIP-2 messages are broadcast;
  354.    RIP-2, in which RIP-2 messages are multicast; and "none", which
  355.    disables the sending of RIP messages.  The recommended default
  356.    for this switch is RIP-1 compatibility.
  357.  
  358.    For completeness, routers should also implement a receive control
  359.    switch which would determine whether to accept, RIP-1 only, RIP-2
  360.    only, both, or none.  It should also be configurable on a
  361.    per-interface basis.
  362.  
  363. 4.2 Authentication
  364.  
  365.    The following algorithm should be used to authenticate a RIP message.  If
  366.    the router is not configured to authenticate RIP-2 messages, then RIP-1
  367.    and unauthenticated RIP-2 messages will be accepted; authenticated
  368.    RIP-2 messages shall be discarded.  If the router is configured to
  369.    authenticate RIP-2 messages, then RIP-1 messages and RIP-2 messages
  370.    which pass authentication testing shall be accepted; unauthenticated
  371.    and failed authentication RIP-2 messages shall be discarded.  For
  372.    maximum security, RIP-1 messages should be ignored when authentication
  373.    is in use (see section 4.1).
  374.  
  375.    Since an authentication entry is marked with an Address Family
  376.    Identifier of 0xFFFF, a RIP-1 system would ignore this entry since
  377.    it would belong to an address family other than IP.  It should
  378.    be noted, therefore, that use of authentication will not prevent
  379.    RIP-1 systems from seeing RIP-2 messages.  If desired, this may
  380.    be done using multicasting, as described in sections 3.5 and 4.1.
  381.  
  382. 4.3 Larger Infinity
  383.  
  384.    While on the subject of compatibility, there is one item which people
  385.    have requested: increasing infinity.  The primary reason that this
  386.    cannot be done is that it would violate backwards compatibility.  A
  387.    larger infinity would obviously confuse older versions of rip.  At
  388.    best, they would ignore the route as they would ignore a metric of
  389.    16.  There was also a proposal to make the Metric a single octet and reuse
  390.    the high three octets, but this would break any implementations which
  391.  
  392.  
  393.  
  394. Malkin                      Expires: 1Mar94                     [Page 7]
  395.  
  396. Internet Draft               RIP Version 2                  October 1992
  397.  
  398.  
  399.    treat the metric as a 4-octet entity.
  400.  
  401. 4.4 Addressless Links
  402.  
  403.    As in RIP-1, addressless links will not be supported by RIP-2.
  404.  
  405.  
  406. 5. Security Considerations
  407.  
  408.    The basic RIP protocol is not a secure protocol.  To bring RIP-2
  409.    in line with more modern routing protocols, an extensible authentication
  410.    mechanism has been incorporated into the protocol enhancements.  This
  411.    mechanism is described in sections 3.1 and 4.2.
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Malkin                      Expires: 1Mar94                     [Page 8]
  451.  
  452. Internet Draft               RIP Version 2                  October 1992
  453.  
  454.  
  455. Appendix A
  456.  
  457.    This is a simple example of the use of the next hop field in a rip entry.
  458.  
  459.       -----   -----   -----           -----   -----   -----
  460.       |IR1|   |IR2|   |IR3|           |XR1|   |XR2|   |XR3|
  461.       --+--   --+--   --+--           --+--   --+--   --+--
  462.         |       |       |               |       |       |
  463.       --+-------+-------+---------------+-------+-------+--
  464.         <-------------RIP-2------------->
  465.  
  466.    Assume that IR1, IR2, and IR3 are all "internal" routers which are
  467.    under one administration (e.g. a campus) which has elected to use
  468.    RIP-2 as its IGP. XR1, XR2, and XR3, on the other hand, are under
  469.    separate administration (e.g. a regional network, of which the campus
  470.    is a member) and are using some other routing protocol (e.g. OSPF).
  471.    XR1, XR2, and XR3 exchange routing information among themselves such
  472.    that they know that the best routes to networks N1 and N2 are via
  473.    XR1, to N3, N4, and N5 are via XR2, and to N6 and N7 are via XR3. By
  474.    setting the Next Hop field correctly (to XR2 for N3/N4/N5, to XR3 for
  475.    N6/N7), only XR1 need exchange RIP-2 routes with IR1/IR2/IR3 for
  476.    routing to occur without additional hops through XR1. Without the
  477.    Next Hop (for example, if RIP-1 were used) it would be necessary for
  478.    XR2 and XR3 to also participate in the RIP-2 protocol to eliminate
  479.    extra hops.
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Malkin                      Expires: 1Mar94                     [Page 9]
  507.  
  508. Internet Draft               RIP Version 2                  October 1992
  509.  
  510.  
  511. References
  512.  
  513.    [1] Hedrick, C., Routing Information Protocol, Request For Comments
  514.        (RFC) 1058, Rutgers University, June 1988.
  515.  
  516.    [2] Malkin, G., RIP Version 2 - Carrying Additional Information,
  517.        Request for Comments (RFC) 1388, Xylogics, Inc., January 1993.
  518.  
  519.    [3] Malkin, G., and F. Baker, RIP Version 2 MIB Extension, Request
  520.        For Comments (RFC) 1389, Xylogics, Inc., Advanced Computer
  521.        Communications, January 1993.
  522.  
  523.  
  524. Author's Address
  525.  
  526.    Gary Scott Malkin
  527.    Xylogics, Inc.
  528.    53 Third Avenue
  529.    Burlington, MA 01803
  530.  
  531.    Phone:  (617) 272-8140
  532.    EMail:  gmalkin@Xylogics.COM
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Malkin                      Expires: 1Mar94                    [Page 10]
  563.